At the present time, VLSI design is described in blocks and sub-blocks using a high-level language such as Verilog or VHDL and simulated by behavioral, gate-level Verilog/VHDL simulators. Such simulation is targeted to check the functionality and performance before the design is fabricated into silicon IC.
Design validation is one of the most important and difficult tasks in complex IC design because without full functional verification, design errors are not found and removed. At the same time, design validation is an absolute necessity in the product development cycle. Because of the slow simulation speed and large size of present day designs, chip level design validation is almost an impossible task with the present day tools and methodologies (M. Keating and P. Bricaud, “Reuse methodology manual for system-on-a-chip design”, Kluwer Academic publishers, 0-7923-8175-0, 1998; R. Rajsuman, “System-on-a-Chip: Design and Test”, Artech House Publishers Inc., ISBN 1-58053-107-5, 2000).
An example of such a complex IC is a system-on-a-chip (SoC) which is an IC designed by stitching together multiple stand-alone VLSI designs (cores) to provide full functionality for an application. FIG. 1 illustrates an example of general structure of an SoC 10 that has an embedded memory 12, a microprocessor core 14, and three function-specific cores 16, 18 and 20, PLL (phase lock loop) 22 and TAP (test access port) 24. In this example, chip level I/Os are established as chip I/O pads 28 formed on a I/O pad frame 26 at the outer periphery of SoC 10. Each of the cores 12, 14, 16, 18 and 20 includes a pad frame 29 which typically contains multiple I/O pads at its periphery with power pads on the top metal layer.
Design validation is one of the most important tasks in any system design project such as a design of SoC 10 noted above (R. Rajsuman, “System-on-a-Chip: Design and Test”). Design validation means establishing that the system does what it intended to do. It essentially provides a confidence in system operation. The objective of validation is to prove that the product indeed works as intended (find out if it works as intended). Design validation of complex ICs can be considered as validation of hardware operation, which includes both functionality and timing performance. In the present day technology, it is obtained by extensive behavioral, logic and timing simulation; and/or by emulation; and/or by hardware prototype.
In the early phase of an IC design, along with the specification development and RTL coding, behavioral models are developed so that the testbenches can be created for system simulation. In the early phase, the objective is generally to develop a good set of test suites and test cases by the time RTL and functional models are specified. Efficient validation depends on the quality of test and completeness of testbenches, the abstraction level of various models, EDA tools and the simulation environment.
FIG. 2 illustrates the complex IC design at different levels of abstraction and what type of verification methodology is used today at each level. From the highest to lowest abstraction levels, FIG. 2 shows behavioral HDL level 41, RTL (register transfer language) level 43, gate level 45 and physical design level 46. Verification methods corresponding to such different abstraction levels are listed in a block 48 of FIG. 2.
The design validation strategy follows design hierarchy. First the leaf level blocks are checked for correctness in a stand-alone way. After functionality checking of these blocks, the interfaces between the blocks are checked for correctness in terms of transaction types and in data contents. The next step is to run application software or equivalent testbenches on full-chip model. As application of software can only be verified by runtime executions of the software, a hardware-software co-simulation is required. Co-simulation can be done at an instruction set architecture (ISA) level, a bus functional model (BFM) level or using a behavioral C/C++ model.
An approximate comparison of simulation speed at different levels is shown in FIG. 3. Because of the slow co-simulation speed, at the present time, emulation and/or hardware prototypes are used. Emulation speed is much faster than the speed of co-simulation, although emulation is quite expensive (in general, emulation system cost on the order of 1 million dollars). Emulation can be close to 1/100 of the actual system speed (roughly about 1,000,000 cycles/sec) FPGA (field programmable gate array) or ASIC (application specific integrated circuit) based hardware prototype provides even faster simulation speed, up to 1/10 of the actual system speed, but it is even more expensive than emulation as it requires manufacturing of FPGAs or ASICs.
Despite the best attempt by engineers to make the first silicon fully functional, only about 80% designs work correctly when tested at the wafer level, but more than half fail when put into the system for the first time. The primary reason is the lack of system level testing with sufficient amount of real application run. The only means to do it in the present day technology is by silicon prototypes using either FPGA or ASIC.
An example of the present day product development cycle is illustrated in FIG. 4. At stage 51, designers study the requirements of a complex IC to be designed. Based on the requirements in the stage 51, the designers determine the specifications of the IC at stage 52. In the design entry process in stage 53, the IC is described in blocks and sub-blocks using a high-level language such as Verilog/VHDL. In stage 54, an initial design evaluation is made through design verification 55 and logic/timing simulation 56 with use of initial testbenches 58. As a result of executing the logic simulation, an input/output data file or VCD (value change dump) file 59 will be created. The data in the VCD file 59 is a list of input and output events with respect to time lengths or delays, i.e., data in an event format.
As shown in FIG. 4, when design is too large, building a silicon prototype and debugging it in the final system is the only method available today that is practical in comparison to extended verification and co-simulation. Such silicon prototype fabrication, verification and bug fix processes are illustrated in a shaded area 60 of FIG. 4. In this process, at stage 61, fabrication is done to obtain a silicon prototype 63. The resultant silicon prototype 63 is examined in stage 62 for any error, these errors are debugged in debug and verification test 65.
Today, such test is carried out with use of an IC tester which is a cycle based test system having an architecture for generating test vectors based on test pattern data in a cycle format. Since cycle based test systems (ATE systems) are not able to directly utilize the testbench 58 or VCD file 59 produced under the EDA environment, such verification by IC testers today involves incomplete and inaccurate results. It is also time consuming to convert the event format data from the EDA environment to the cycle format test pattern data for the cycle based test system.
The silicon prototype 63 is further validated through an in-system test 67 wherein the silicon prototype 63 is tested as a part of an intended system. Suppose that the particular design is a chip to be installed in a cellular phone, the silicon prototype representing the chip will be mounted on a board of the cellular phone and is tested based on intended functions and performances of the cellular phone. During the in-system validation, errors and causes of the errors will be detected and the design bugs will be fixed in stage 69. Since such an in-system test requires both a silicon prototype of the designed chip and a system with application software to run the silicon prototype, it is not only costly but also time consuming.
During the silicon verification and the in-system test in the shaded area 60 in FIG. 4, design errors are found and causes of such errors are determined and design errors are corrected through repeated interactions between design engineers and test engineers. The final design 71 will be reached and the logic/timing simulation 73 for the final design 71 will be conducted with use of a new testbench 75. Then the design will be fabricated to silicon 79 and a production test 77 will be performed on the silicon 79.
In the foregoing process with silicon prototype, same silicon can be used for first several bugs without new silicon run. However, deciding when to use silicon prototype is an important decision as silicon prototype is a costly proposition. The following factors are considered in silicon prototyping:
(1) Diminishing bug rate in verification and co-simulation. When the basic bugs are eliminated, extensive application run will be required to find other bugs. Co-simulation and emulation may not be able to run application for extensive time periods.
(2) Difficulty in finding a bug. If finding a bug takes few orders of magnitude more time than the time to fix it, then silicon prototype is very useful, as it will help finding bugs quickly.
(3) Cost (manual effort, time-to-market) of finding bugs. If finding a bug in co-simulation or emulation is extremely costly, then silicon prototyping becomes necessary.
For smaller designs, FPGA/LPGA (field programmable gate-array/laser programmable gate-array) prototypes are adequate. LPGAs allow re-programmability so the bug fixes can be re-tested, while FPGAs offer higher speeds and higher gate counts than LPGAs. Both FPGA and LPGA lack the gate count capacity and speed of ASICs, thus they are good for smaller blocks, but not suitable for a large complex chip.
Several FPGAs can be used to build a prototype of a large complex chip, while each FPGA implements a portion of the chip. In this case, if bug fix demands re-partitioning of the chip, interconnects between FPGAs may require change and hence modifications can be complex. A partial solution of this problem is to add custom programmable routing chips to interconnect FPGAs. With programmable routing chips, if the interconnects change, new routing can be done under software control.
In a prototype design flow, after the study of the system behavior, simulated HDL (Verilog/VHDL) and/or C-programs description is used in co-synthesis. Similar to co-simulation, co-synthesis means the simultaneous development of the hardware and software. The purpose of co-synthesis is to produce C-code and hardware that will execute on a real architecture. In general, this step consists of mapping the system onto a hardware-software platform that includes a processor to execute the software and a set of ASICs to realize the hardware. The final prototype is generated by using the C-code of the software parts and by using logic synthesis, placement and routing to create the hardware components. Synthesis tools translate the HDL descriptions/models into gate-level netlist that are mapped to FPGAs or ASICs as prototypes.
The design validation method in the conventional technology described above is either extremely high in cost (e.g., method using a silicon prototype) or extremely slow in speed (e.g., method using a co-simulation). The design validation method today involves different formats between the EDA environment and the tester environment, and thus not able to perform the design validation with high efficiency and accuracy. Further, the design validation method today requires the in-system test as noted above which involves hardware and software to run the design in an intended system and requires significant feedbacks and interactions between the test environment and the design environment, resulting in a long turnaround time.